It is known from the state of the art to enable terminal equipment to access a mobile communication network, e.g. a 3GPP (3rd generation partnership project) network, via a node which is attached to the mobile communication network. Thereby, a terminal equipment device, e.g. a portable computer, is able to exchange data with a peer device, e.g. an Internet server, via the mobile communication network. The node may be realized for example by a mobile terminal, which can be connected physically or via the air interface with the terminal equipment device.
An important aspect of such an environment which has not been standardized yet is the quality of service (QoS) management for involved packet switched data transmissions.
Currently, there is no effective way for a terminal equipment device to request a QoS profile for a data flow. A QoS profile can only be requested by a terminal equipment device through AT commands. AT commands, however, are quite clumsy, and it is not likely that terminal equipment applications would start to configure AT commands extensively in order to have the needed QoS. AT commands are moreover not scalable to scenarios where several QoS profiles are needed simultaneously.
Known flexible QoS management solutions do not take account of requirements by terminal equipment accessing a mobile communication network via a node which is attached to this network.
Document WO 00/76230 A1 proposes a method to control the PDP (packet data protocol) context of a data packet in a mobile terminal, which contains one or several applications performing packet format data transfer. First, a data packet is received from an application. The data packet contains a first identifier to identify the application that has created the packet. Then, input data pertaining to this application is received. The input data contains information about one or several data flows of the application. On basis of the input data, a PDP context is defined for each data flow of the application. Further, a second identifier indicating the data flow is added to the data packet. Finally, the departing data packet is classified into a PDP context on basis of the first and the second identifier.
Document WO 99/39480 A2 aims at supporting a flexible determination of the QoS in packet switched transmissions between a wireless communication device and an information network. The wireless communication device accesses a radio network, and data transmissions between the mobile terminal and the radio network are controlled by an access point controller. For setting up an Internet connection, the required QoS for the connection is determined, for example centrally by the access point controller. Then, it is attempted to establish the connection in the wireless communication network with parameters complying with the set QoS.
A possibility for enabling terminal equipment accessing the information network via the wireless communication device to influence the employed QoS is not dealt with in documents WO 00/76230 A1 and WO 99/39480 A2.
Similar problems may occur in other, similar environments, in which a unit desires to ensure a specific QoS for the transmission of data packets from a node which is attached to a mobile communication network to some other unit.
The mentioned problems are also of particular relevance for IP Multimedia Core Network Subsystems (IMS).
IMS was introduced in 3GPP Release 5 and is intended to provide IP (Internet protocol) based telephony and multimedia sessions with security and charging on top of 3G RAN (radio access network) and packet core infrastructure. In addition to basic telephony services, IMS should be able to provide SIP (session initiation protocol) based presence and messaging services. IMS can also be used to set up sessions related to all types of services, such as network gaming.
In IMS sessions, media is delivered directly from user equipment to user equipment, or from user equipment to Media Gateway or Media Resource Function, e.g. in RTP/UDP/IP (real time protocol/user datagram protocol/Internet protocol) packets. For this, end-to-end QoS is required in RAN, GPRS (general packet radio service) and IP core network (CN). However, session establishment, modification and teardown (i.e. the signaling plane) using the SIP protocol requires several application level servers, such as Call State Control Functions (CSCF). The role of CSCFs is to route the session establishment, to interact with authentication and accounting, and to act as the focal point in session related services through the interaction with UMS (unified messaging service) and Application Servers. UMS is a central repository for all subscriber-related data, including the authentication keys.
IMS interacts with Circuit Switched (CS) networks such as a PSTN (public switched telephone network) through Media Gateways and Media Gateway controllers. A subscriber is also able to roam between IMS and CS CN domain.
In theory IMS is completely independent of RAN and GPRS, i.e. it only requires an IP packet transport with a requested QoS from them. For example, IMS registration and authentication are completely separate and independent from the GPRS procedures. However, in reality IMS interfaces with GPRS to tie together the authorization of an IMS session and a PDP context carrying media for it. The main benefit from this to the operator is the ability to combine GPRS and IMS services and charging. However, separate GPRS and IMS subsystems are also possible without this kind of tight coupling. An IMS-GPRS interface is used to handle situations in which a user equipment leaves radio coverage or shuts down during an existing IMS session. This indication is needed in IMS to release session related state. The interaction between IMS and RAN is minimal. In some situations it would be beneficial for an IMS functional element to know which kind of radio interface a user equipment is using to optimize session related procedures, e.g. media streams or the usage of message compression.
IMS and a services subsystem interact with each other directly. From IMS point of view, a services subsystem is a combination of Application Servers, which can offer session-related services to subscribers. The interaction happens from Serving CSCF using an ISC (international switching center) protocol interface. A services subsystem is also able to offer non-session related services, such as instant messaging, push and presence to IMS endpoints.
IMS is built based on IETF (Internet engineering task force) protocols, such as SIP, SDP (session description protocol), RTP and Diameter. In some cases, extensions to these protocols are needed to either add new functionality, to optimize their usage in wireless environment or to utilize existing Release 99 solutions. The preferred way has been to do extensions, not modifications.